PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 4/USEnet 4.43

Text File | 1988-06-15 | 24.6 KB | 643 lines | [TEXT/ttxt]

28-Mar-88 12:05:05-PST,25770;000000000000
Return-Path: <[e-mail]>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Mon, 28 Mar 88 12:00:37 PST
Received: from relay2.cs.net by RELAY.CS.NET id ax16700; 28 Mar 88 12:01 EST
Received: from relay.cs.net by RELAY.CS.NET id aa19449; 28 Mar 88 11:37 EST
Received: from sdr.slb.com by RELAY.CS.NET id ak19391; 28 Mar 88 11:33 EST
Date: Mon, 28 Mar 88 09:39 EDT
From: Jeffrey Shulman <[e-mail]>
Subject: Usenet Mac Digest V4 #43
To: [e-mail], [e-mail]
X-VMS-To: in%"[e-mail]",in%"[e-mail]"

Date: Mon 28 Mar 88 09:39:17-GMT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V4 #43
To: Usenet-List: ;
Message-ID: <575545157.0.SHULMAN@SDR>
Mail-System-Version: <VAX-MM(218)+TOPSLIB(129)@SDR>

Usenet Mac Digest     Friday, March 25, 1988         Volume 4 : Issue 43

Today's Topics:
     Warning: Debugger causes system crashes
     Allegro CL Benchmarks
     cheap 2400-baud modem summary
     Re: Quitting the Finder under MF
     Addition/Patch suggestion to Finder
     swapping ram chips
     Dialog Boxes with Scrollable region
     Re: Apple's Video Exansion Kit
     Re: HELP- PLEASE! Need address of ATMS Authors
     ResEdit
     Polygon question
     Bitmap to Region conversion
     MFKeys question
     accurate timing for send/receive of MIDI data
     Re: Allegro CL strangeness; info request (2 messages)

----------------------------------------------------------------------

From: [e-mail] (Ed Anson)
Subject: Warning: Debugger causes system crashes
Date: 22 Mar 88 14:34:56 GMT
Organization: Calcomp, A Lockheed Company, Hudson, NH, USA

This may be old news to some, but it just bit me and might bite someone
else: There is a version of the Maxbug debugger which causes system
crashes if more than 1 Mb of RAM is installed.  My copy shows a creation
date of Mon, May 13, 1985 3:38 PM.  A more recent version appears to
have solved the problem.

About two weeks ago, I started experiencing frequent system crashes.
Usually, the cursor froze, but bomb boxes occurred and the display
occasionally freaked out.  These failures were mostly repeatable, but
varied with the context.  I suspected memory or logic failures, and took
my Mac to the shop.  After all, I have AppleCare :-(

The tech at the shop ran every diagnostic he had, and even spilled Coke
on the screen.  It wouldn't fail for him.  I brought in my hard disk and
made it fail immediately.  The same hard disk worked on another Mac.
Then he removed my Dove memory upgrade, and everything worked.  He
marked the upgrade "NG" and billed me $125.  I made him put the memories
in a protective bag, and took them home with me.

I then had several lengthy talks with the Tech Support people at Dove.
They told me several things that had caused other people's upgrades to
fail even with good memories.  I tried their suggestions, but to no
avail.  Then I got them to tell me how the memories mapped into the
address space.  I wrote a quick and dirty memory diagnostic, and found a
range of addresses where a write would cause the system crash.  I then
moved the memories around, expecting to see the bad locations move.
They didn't.

I won't go into any more detail.  The bottom line is: After two weeks
and $125, I discovered that the version of Maxbug I was using was
stepping on the memory.  It apparently assumes that 1 Mb is the biggest
any Mac will ever be. :-)  It installs itself right under the screen
memory.  Unfortunately, when a second meg is added, the screen memory
moves but Maxbug doesn't.

I received my copy with the Lightspeed C distribution a coupla years
ago.  I have seen a fixed version included with the more recent
distributions, but even though I am upgraded to version 2.15 I still
have the old version of the debugger.  I got fooled, since I "knew" the
debugger worked.  After all, it'd been around for two years.  I have it
turned off most of the time,  and it took awhile to realize that the
crashes started happening the first  time I turned it on after upgrading
the memory.

MORAL (lessons I learned the hard way):
 1. Always remove third-party stuff before going in for Apple service.
 2. Don't always assume that something caused the problem just because
    removing it makes the problem appear to go away.
 3. Sometimes the debugger is the bug.
 4. At least it wasn't a virus.
--
=====================================================================
   Ed Anson,    Calcomp Display Products Division,    Hudson NH 03051
   [phone],      [e-mail]


------------------------------

From: [e-mail] (Jeffrey A. Sullivan)
Subject: Allegro CL Benchmarks
Date: 22 Mar 88 20:25:03 GMT
Organization: Univ. of Pittsburgh, Comp & Info Sys

Here is a benchmark examination of Coral Allegro CL vs Lucid CL that is
part of a review article I did for our ITS Newsletter.  Sorry the
formatting is not great, but it's the best I could do on short notice.

I also tried to run the gabriel suite on Lyric CL from Xerox, but the
first one took so long to run (never stopped in 5 minutes) that I gave
it up.  If someone has the gabriel suite for Lyric CL, I'd like to see
it.

Also, there is a benchmark listing in a past issue of BYTE.  I can't
recall which.

Benchmarks

In order to determine the relative efficiency of Allegro CL, the Gabriel
suite of benchmarks was run in Allegro CL and Lucid CL on a Vax 8860.
The results appear below.


    Allegro    Optimized Allegro    Vax (C)    Vax (I)
Boyer    36.000    23.050    7.81/1.01    418.12/26.66 Browse    65.233
    52.800    8.87/0.58    587.73/37.06 CTAK    4.317     3.500    0.74/0.01    35.81/2.99
Dderiv    31.933/4.267     31.017/4.283    3.83/0.2    48.02/2.68
Deriv    32.250/4.183    31.350/4.183    3.06/0.18    54.84/2.03
Destructive    9.017    7.383    0.99/0.09    113.85/1.44
Div-iter    5.333    3.117    1.99/0.11    98.85/6.22
DiOAv-rec    5.000    2.667    2.43/0.08    58.96/4.17
FFT    67.083/4.233    66.550/4.217    41.59/2.13    433.94/28.56
Fprint    9.650    9.567    0.6/0.06    0.63/0.03
Fread    3.700    3.333    1.26/0.13    1.23/0.04 Frpoly Power=2
r=x+y+z+1    0.033    0.050    0.0    0.3/0.02 Frpoly Power=2 r2=1000r    0.017
    0.017    0.01    0.17/0.01 Frpoly Power=2 r3=r in
flonums    0.017    0.017    0.02    0.18/0.01 Frpoly Power=5
r=x+y+z+1    0.167    0.117    0.02    1.61/0.13 Frpoly Power=5
r2=1000r    0.233    0.183    0.06/0.02    1.72/0.11 OAFrpoly Power=5 r3=r in
flonums    0.183    0.150    0.04    1.6/0.16 Frpoly Power=10
r=x+y+z+1    1.517    1.167    0.22/0.02    18.2/1.27 Frpoly Power=10
r2=1000r    2.633    2.283    0.73/0.02    17.69/0.74 Frpoly Power=10 r3=r in
flonums    1.900    1.550    0.36/0.01    18.07/0.82 Frpoly Power=15
r=x+y+z+1    9.767    7.567    1.54/0.13    115.77/1.78 Frpoly Power=15
r2=1000r    20.550    18.200    7.25/0.5    124.55/3.61 Frpoly Power=15 r3=r in
flonums    12.133    9.867    3.83/0.24    118.95/3.26 Puzzle    69.283
    68.267    20.29/0.87    823.23/46.0 STAK    15.200    15.667    0.77/0.03    45.38/0.86
TAK    1.250    0.700    0.26    29.48/0.26 TAKL    13.100    7.133    0.91    263.66/4.39
TAKR    1.433    0.917    0.38/0.03    29.75/0.56
Tprint    29.883    31.600    0.79/0.04    0.8/0.04
Traverse-init    36.533    35.517    5.57/0.29    913.73/85.41
Traverse    135.017    133.967    20.07/1.17    >2600

Note:  The optimized Allegro column refers to compiled benchmarks
including the form     (declare (optimize (speed 3) (size 0) (safety 0) ...
) wrapped around them.  The difference between the Lucid CL benchmarks
when compiled and interpreted is quite marked.  The (C) column refers to
files loaded with (load "file.vbin") after (compile-file "file.cl") has
been completed.  The (I) column refers to files loaded with (load
"file.cl").

--
..........................................................................
Jeffrey Sullivan              | University of Pittsburgh
[e-mail]          | Intelligent Systems Studies Program
[e-mail], [e-mail] | Graduate Student


------------------------------

From: [e-mail] (Kelvin Thompson)
Subject: cheap 2400-baud modem summary
Date: 23 Mar 88 15:30:01 GMT
Organization: U. Texas CS Dept., Austin, Texas

This is a summary of some netters' evaluations of inexpensive 2400-baud
modems.

First, thanks to everybody who replied to my query.  Your repsonses will
make me feel a lot more comfortable about buying a modem in a few days.

My query concerned two cheap modems I saw in the April 1988 MacUser,
plus a third, suggested by two of the respondents:

   Practical Peripherals  $189  p. 125 MacUser (MacConnection)
   Anchor                 $169  p. 158 MacUser (STF mail order)
   Qubie                 ~$169  Byte Magazine

I got the most responses about the Practical Peripherals modem.
Everybody that had used one was happy with it.  People liked the modem's
speaker, multiple status lights, and good Hayes compatibility.
'[e-mail]'  noted it comes with trial subscriptions to OAG,
CompuServe and the Source. '[e-mail]' said he did a lot of
looking around before deciding to get the PP modem.

On the down side, '[e-mail]' said he had some trouble
doing  file transfers with CompuServe -- but not GEnie -- with the PP
modem. Two people warned that the MacConnection price for the modem does
not include a "cable" (to the Mac? to Ma Bell? I don't know).

Nobody had used a 2400-baud Anchor, but '[e-mail]' had used
a 1200-baud Anchor modem and found some gaps in its Hayes compatibility
(and that it didn't have a speaker).  He said the Anchor 1200 never gave
him any trouble over years of use, though.

Two people recommended the Qubie, which does not advertise in
Mac-related magazines, but which seems to work okay with the Mac.
'[e-mail]' said the main drawback of the Qubie was its
loud, unadjustable speaker.

'[e-mail]' said the reason these modems can be so cheap is
that they don't have sophisticated noise-handling features.  To use
cheap modems  on noisy lines, you have to switch them to 1200 baud,
while the more  expensive ones can correct some errors and negotiate
slowdowns with other  smart modems.

I certainly hope this summary has helped to promote world peace.
--
-- Kelvin Thompson, Lone Rider of the Apocalypse
   [e-mail]  {ihnp4,ctvax,seismo,ucbvax}!ut-sally!im4u!kelvin


------------------------------

From: [e-mail] (Phil Goldman)
Subject: Re: Quitting the Finder under MF
Date: 23 Mar 88 22:47:24 GMT
Organization: Apple Computer Inc, Cupertino, CA

In article <[e-mail]> [e-mail] (Jim Meiss) writes:
>...
>What happened though, was that the finder quit too. So here I was running
>PrintMonitor only, with the MF icon in the upper right, and no "Finder" in
>the Desk accessory menu, or anywhere! Wow! I always wanted to be able to
>run applications without the finder, and there I was. I still could get
>to my DA's and they ran under the DA Handler, which upon quiting gave me
>back PrintMonitor. I finally hit the debug button and got the finder
>back by SM 0 A9F4, G 0. But the system was in an unstable state...As
>was my heart.


Just like any other application, the Finder can crash.  When this
happens, the user is not informed since it is the job of the Finder to
do the informing. When you quit all other apps, a new Finder will
automatically be launched. Until then, you are running "Finder-less".

One more note:  There is nothing in MultiFinder that prevents the Finder
from quitting, there is simply no way for the user to convince the
Finder to do so.
--
-Phil Goldman
Apple Computer


------------------------------

From: [e-mail] (Jeff A. Hallett)
Subject: Addition/Patch suggestion to Finder
Date: 23 Mar 88 14:45:22 GMT
Organization: General Electric CRD, Schenectady, NY


A friend of mine and I were talking the other day and we came up with a
good idea.  I'm sure you all are familiar with how the "Get Info"
comments disappear when the desktop is rebuilt.  Discussions have been
made about making these comments more concrete.  We thought it would be
a good idea for someone to write an INIT patch to the Finder Get Info
routine.  The basic PDL might be below:

   begin
     if (application has new "info" resource)
        load the info resource into comment field of get info box;
     else
        load creator/version resource into get info box;

     do "get info" as usual;

     wait(get info window is closed);

     when info window is closed, extract the get info comment field
        and save it in the "info" resource of the application
        (creating it if necessary);
   end

It doesn't seem like it would be too hard for a real guru to pull off
(check out the QuickFolder init - that's a real trick too).

How about it?  I couldn't do it (yet :^)).
--
Jeffrey A. Hallett                     | ARPA: [e-mail]
Software Technology Program               | UUCP: desdemona![e-mail]
GE Corporate Research and Development  | [phone]
+--------------------------------------+--------------------------------------+
|                            Credo Quia Absurdum Est                          |
+-----------------------------------------------------------------------------+


------------------------------

From: [e-mail] (Scott Paisley)
Subject: swapping ram chips
Date: 23 Mar 88 20:01:20 GMT
Organization: National Bureau of Standards, Gaithersburg, MD

Question:

    Let's say that the chip shortage is over.  Anyone else think that when
the supply of chips catches up that there will be a huge decrease of
price?  :-)

    Next question.  How many layers are the simm boards anyway? 2 layer?  4
layer?  Actually what I'm trying to find out is, would it be possible to
use the old 256 simms in my MacPlus, remove the old 256 chips and put in
the the 1M chips in there place?  Is this cheaper? Can someone who can
hold a solder iron do this?  It seems that one could get chips alot
cheaper than simms and save some bucks.  But is it worth it?
--
"Why move around the world - Eden was so Near."
Scott Paisley        ARPA   : [e-mail] (prefered)
                 [e-mail]
            BITNET : paisley@cmeamrf


------------------------------

From: [e-mail]
Subject: Dialog Boxes with Scrollable region
Date: 21 Mar 88 15:15:00 GMT

I am trying to build a dialog box with a scrollable region embedded in
it, similar to the SF Getfile box or the MS Word help box.  It all
looked so straightforward...just create a UserItem and do the obvious
thing.

The catch is that ModalDialog does not give you any information about
the event - only the item number of the hit on a mouse click.  So there
seems no way to actually find out that the scroll bar was clicked upon
rather than the textual portion of the item.  One hack is to use a
filter function to ModalDialog to save the coordinates of each mouse
click.  This would presumably work, but it still does not allow you to
do continuous scrolling in the [page|line][up|down] regions.  Also, this
is an incredible hack.  I can't believe it is the right way to do it.

So, what obvious thing am I missing?  Please reply by E-mail; I will
summarize for the net if there are enough responses.  Thanks in advance.
--
Roger Lipsett
{ihnp4,mirror,sun}!inmet!lipsett


------------------------------

From: [e-mail]
Subject: Re: Apple's Video Exansion Kit
Date: 24 Mar 88 06:14:00 GMT


1.  The video expansion is *JUST* memory.  8 41264-150 video DRAMs  Made
by NEC Electronics (only supplier), 150ns access time -- o.k. to
substitute 120ns or 100ns parts.

2.  I bought my own expansion for $46 ($5.50 each + tax) from FRYE's
electronics in Silicon Valley (Sunnyvale Information: 415-555-1212, they
mail-order free).  I got 120ns parts for the money 3 weeks ago. My Mac
II runs great in 8-bit mode.  Be careful to ground yourself when you
install the memory.

3.  There is a severe shortage of *THESE* *VIDEO* *DRAMS* right now.
Most mail-order houses will quote $8-$9 EACH, or more.  The DRAMs are
being sold to OEMs, and chip quotas has caused a memory shortage.

4.  If the shortage has subsided, call microprocessor's unlimited (back
of BYTE).  Otherwise, try calling FRYE's.  Or find a local distributor
with stock-on-hand that hasn't marked up his prices yet.

Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
            {[e-mail]}


------------------------------

From: [e-mail] (David Hornsby)
Subject: Re: HELP- PLEASE! Need address of ATMS Authors
Date: 24 Mar 88 03:39:13 GMT
Organization: Comp Sci, Melbourne Uni, Australia

In article <[e-mail]>, [e-mail] (Macintosh Users Gp)
writes:
>
> Here is the address of one of ATMS's authors.
>
> Jason Castan
> ....junk.....
> Australia 3124
>
> Jason Haines, President
> Club Mac - Australia's Largest Macintosh Users Group

The OFFICIAL address for ATMS enquiries is ...

    ATMS
    David Hornsby
    Department of Computer Science
    Richard Berry Building
    University of Melbourne
    Parkville 3052, Victoria, Australia.

or
    ...!uunet!munnari.oz!djh

Jason (Castan) will probably politely ignore mail sent directly to him
...

More details:

    The release version is available for US$99 from the above address.
    It includes a printed manual, several demonstration programs and
    ATMS version 2.03. The question of site licenses has been addressed
    and the policy is to charge US$300 per educational institution.
    This entitles you to 2 copies of discs, manuals etc. and permission
    to make further copies for student use.

 - David.


------------------------------

From: [e-mail] (Rick Giles)
Subject: ResEdit
Date: 23 Mar 88 11:55:52 GMT
Organization: School of Computer Science, Acadia Univ., Nova Scotia

Apparently one can write an add-on editor for ResEdit. I am considering
doint this; writing drivers in Lightspeed C. Has anyone used Lightspeed
C to do this and, if so, could they send me info on the techniques/tools
they used? Thanks.

Rick Giles


------------------------------

From: omh@nancy (Owen M. Hartnett)
Subject: Polygon question
Date: 23 Mar 88 04:32:44 GMT
Organization: Brown University Computer Science Dept.


Does anyone have a good method for determining the area (square pixels)
of a Macintosh polygon?  The method I'm going to use would be to copy it
to a blank offscreen bitmap, then scan through the bits looking for an
edge, then count bits until I hit the next edge.

Any better ways (or a fast algorithm to do the above??)

Thanks,

Owen
--
Owen Hartnett
Brown University Computer Science

[e-mail]
omh%cs.brown.edu
{ihnp4,allegra}!brunix!omh

"Don't wait up for me tonight because I won't be home for a month."
            -W.C. Fields


------------------------------

From: cs224052@brap0aa3 (Scott Draves)
Subject: Bitmap to Region conversion
Date: 23 Mar 88 19:16:45 GMT
Organization: (SAE) Students Against Education


I need to convert a bitmap into a region, where the region should
contain exactly those bits that are black in the bitmap.  This is so
that I can draw icons with a mask, but I can't use CopyMask, because I
want it to print as well.  CopyBits is a more standard routine anyway
(CopyMask wasn't documented until IM IV). Any ideas?  If if I have to
mess with the Region datastructure itself,
--
then what is it?  Where is it documented?
Giga Thanks,
Scott Draves

PS: Reply to [e-mail]
****


------------------------------

From: [e-mail] (Ken Mitchum)
Subject: MFKeys question
Date: 24 Mar 88 15:15:38 GMT
Organization: Decision Systems Lab., Univ. of Pittsburgh, PA.

In response to a user report, we discovered that MacJove crashes when
used with Multifinder and the MFKeys INIT. On further testing, it seems
that MacJove is not the real problem, as other applications compiled and
linked with LightspeedC also crash with the MFKeys INIT, but that many
other applications work fine with it. Has anyone else experienced this
problem?

 Ken Mitchum
 Decision Systems Laboratories
 University of Pittsburgh


------------------------------

From: [e-mail] (Jeff Faust)
Subject: accurate timing for send/receive of MIDI data
Date: 24 Mar 88 16:31:50 GMT
Organization: Computer Graphics Research Group, Columbus OH


    I'm interested in doing some very accurate timing for a
    MIDI application on the mac. That is, I need a precise timing
    technique for MIDI playback and recording. Using the
    Vertical Retrace Manager seems to be the obvious choice but
    I don't think an interrupt every 1/60 of a second is fast
    enough for this application. Taking over the timer used for
    sound seems to be another choice. I think it interrupts every
    horizontal retrace. Unfortunately, documentation in Inside Mac
    is pretty sparse in this area. I would appreciate hearing about
    better approaches or recommendations on how to solve this problem.


--

Jeff Faust, Graphics Software Research    |
The Ohio Supercomputer Graphics Project    | {cbosgd,ucbvax}!osu-cis!ogg!jeff
The Ohio State University        | [e-mail]
1501 Neil Avenue, Columbus OH 43210    |


------------------------------

From: [e-mail] (Gail Zacharias)
Subject: Re: Allegro CL strangeness; info request
Date: 24 Mar 88 19:54:43 GMT
Organization: A Kindof Entity, Cambridge, MA

In article <[e-mail]> [e-mail]
(Marty Kent) writes:
>non-Listener) window, I notice in the Allegro manual where is says under
>"Drawing Text" (pg. C-7) "Special characters such as return (i.e. from
>TERPRI...) have no effect."

Return means go to next line.  What's a 'next line' in a graphics
window?

>              My first question is, "Who the hell are these
>guys supposed to be kidding??"

Not being a guy, I guess I'll skip this one...

>So, before I go to the trouble of writing something that looks at a window
>and does the right thing with scrolling, as well as font size, does
>anyone have a working TERPRI for Allegro?

This doesn't really have anything to do with TERPRI, TERPRI just asks
the window to output a return.  Vanilla graphics windows do nothing with
the return.  It sounds like you're looking for a specialized kind of
window which behaves like a 'dumb tty'.  This should be fairly easy to
implement, you just need to define its stream-tyo function.  E.g.

    (defobject *dumb-tty-window* *window*)
    (defobfun (stream-tyo *dumb-tty-window*) (char)
      (if (not (eql char #\Newline)) (usual-stream-tyo char)
        (with-port wptr
           <scroll if necessary>
           (move-to <wherever you feel the right place is>))))

>It seems to me from my bit of experimentation with *eventhook* that a
>function bound to the global doesn't in fact get notified of all events.

*eventhook* gets all events that the Lisp gets.  By default, Macintosh
applications don't get mouseUp events.  You can request to get them with
the _SetEventMask trap.

>      I wrote a simple function to print out the fields in certain events
>as they're detected by event-dispatch.  When I grab a window's size
>control, it prints the "what" and msg fields, but won't print the "where"
>field until I unbutton!

Standard output is buffered.  No i/o happens while tracking the size
control so you only see however much of the buffer managed to get
printed out before the tracking started.  When you release the button,
the rest of the buffer gets printed.  Try doing a FINISH-OUTPUT before
returning from your function.


------------------------------

From: [e-mail] (ken ewing)
Subject: Re: Allegro CL strangeness; info request
Date: 24 Mar 88 22:56:09 GMT
Organization: Yale University Computer Science Dept, New Haven CT

That's because the function stream-tyo  simply calls the Mac trap
_drawchar after setting the current port to the port of the window
object which you asked to stream-tyo.  _Drawchar, however, doesn't do
"formatting", because "No formatting (such as carriage returns and line
feeds) is performed by Quickdraw." [Inside Macintosh 1, 172; strangely
mentioned only under the _Drawstring heading].  Anyway, since
plain-vanilla windows are LISP streams of element type string-char, they
should support terpri, fresh-line, format with ~%'s, etc.

But of course, fred-windows do support them fully.  Which brings me to
wonder why you would rather not use fred-windows:  Are you trying to do
text boxes within standard windows?  If so I strongly suggest that you
use the Mac tool- boxes TextEdit routines for handling drawing
characters, scrolling, text selection, etc.  I've had to use boxes of
editable text for a program that I am writing, and rather than dive into
the Mac I chose to use fred-windows by making sets of windows appear and
react as single windows -- a gigantic hack, that even works ok, but NOT
WORTH IT.  The right way is definitesly to create a user-dialog-item
class of TextEdit text boxes, something that Coral should have done for
us.


ken ewing   [e-mail]   [e-mail]

PS:  Boy am I glad to see some Coral Common Lispers out there: I don't
     know 'bout you others, but I've been lonely trying to learn how
     to program this micro with its fancy graphics interface from LISP,
     of all languages!  :-) :-)

------------------------------

End of Usenet Mac Digest
************************
-------